用Claude Code下载AWS云计算鼻祖的3283篇博客：7小时从需求到系统

一句话引发的"奇迹"

Jeff Barr，AWS首席布道师，20年间写了3283篇技术博客，约150万字，记录了云计算从0到1的完整历程。作为研究者，我需要这些文章做离线分析，但手动下载3000多篇？光想想就头疼。10月26日下午2点54分，我在Claude Code里输入了一句话："jeff barr的博客都在哪，如何下载"。7小时后，系统自动下载了483篇文章（进度15%，仍在运行），生成了15个脚本、8份文档，还接入了飞书实时通知——全程我没有写过一行代码。

这不是科幻，这是Claude Code带来的新工作方式：用自然语言描述问题，AI负责设计、编码、测试、部署，你只需要在关键节点做判断。

第一阶段：从一句话到三套方案（14:54-15:30）

我的第一句话很随意："jeff barr的博客都在哪，如何下载"。注意，我没有给出博客地址，没有说明技术要求，甚至连"下载到哪里"都没说。

Claude Code的反应让我意外。它没有直接写代码，而是先做调研：搜索"Jeff Barr blog"，找到AWS官方博客，分析网站结构，识别出作者页面URL，然后发现文章列表采用分页加载，每页约20篇。

13分钟后，我补充了需求："创建目录barr，在目录里下载其全部博客为html文件，按照年份创建子目录，有必要的话编写脚本，使用分级多种方法进行下载，think"。这里的"think"是我从六页纸方法论借鉴的习惯——要求AI先思考再行动。

Claude立即给出了三套方案：方案1-分页爬取（稳定但慢，逐页抓取）、方案2-RSS订阅（快速但可能不全）、方案3-Sitemap（覆盖全面但需要解析XML）。它还自动创建了2004到2025共22个年份目录，以及一个unknown目录（给无法识别日期的文章）。

这些都不是我要求的细节，而是Claude基于最佳实践自主添加的。就像一个有经验的工程师，知道应该"分层设计、容错处理、预留扩展空间"。

第二阶段：意外的复杂度（15:30-16:30）

下午3点46分，我突然想到：这个任务可能要跑好几小时，我怎么知道进度？于是我说："飞书相关配置都在/home/feishu用户目录里，是个api，放在env里，发送给小刘，think"。

这句话信息密度很高，但表达不精确。我说"小刘"，实际应该是"张璐"。我说"飞书api"，但没说清楚用Webhook还是OpenAPI。Claude做了什么？它主动去/home/feishu目录找配置文件，发现了飞书机器人的App ID和Secret，然后自己决定用OpenAPI（可以直接发给个人，而不是群组）。

更巧妙的是，它提供了两套方案：一套基于Webhook（发到群聊），一套基于OpenAPI（直发个人）。在生成的文档中，它做了对比表格，推荐OpenAPI方案（五星）。这种"给选择+给建议"的风格，让我想起写决策文档的经历——好的方案永远有备选和理由。

第三阶段：第一次失败与TDD的弯路（20:00-22:00）

晚上8点，我让Claude获取张璐的Open ID并测试消息发送。测试成功，张璐收到了5条测试消息（包括开始通知、进度通知、完成通知）。然后我启动了下载程序。

8点11分，我看到日志傻眼了："只有8篇么太少了"。第一次运行只下载了8篇文章——问题出在分页处理上，代码只抓了首页的文章列表。

这是整个项目最关键的转折点。我下达指令："分层使用三个方案，使用tdd试错，直到成功处理分页问题，think"。我希望通过测试驱动开发（TDD）系统性解决问题。

Claude开始编写测试用例，测试设计很专业。但问题来了：TDD在爬虫场景下效率太低。每次测试都要真实访问AWS网站，网络延迟、页面变化都会影响结果。写测试、跑测试、改代码、再测试......这个循环太繁重了。

晚上10点13分，我做了一个决定："不要使用tdd，编写小的模块针对方案123，然后测试，成功后集成到总下载程序，直到成功"。这是我在项目中为数不多的主动纠正方向。

Claude立即调整策略，把三个方案拆成独立模块。每个模块职责单一，可以独立测试。这种模块化设计远比TDD高效。

第四阶段：突破与成果（22:00-22:30）

download_method1.py的核心逻辑很简洁：先访问作者页面，解析总页数，然后循环访问每一页提取文章链接。Claude在实现时加入了三个细节：请求延迟（每次间隔1秒，避免被封）、自动重试（失败后重试3次）、断点续传（跳过已下载文章）。这些都不是我要求的，而是基于最佳实践自主添加的。

晚上10点29分，download_method1.py成功运行，爬取了450页，获取了3213篇文章链接。同时，飞书通知也优雅上线。张璐每60秒收到一次进度更新：

📊 Jeff Barr博客下载进度
进度: 150/3213 (4.7%)
███░░░░░░░░░░░░░░░░ 4.7%
成功: 148  失败: 2
更新时间: 20:02:30

这个进度条的实现很巧妙：Claude用Unicode块状字符（█和░）画了一个20格的进度条，每格代表5%。

截至当晚10点30分（项目启动7小时36分钟），系统状态：已下载483篇（进度15%），生成脚本15个，生成文档8份（约2万字），发送通知约100条。更重要的是，整个系统完全可以独立运行——我只需要偶尔看看飞书消息，确认进度正常即可。

亮点：自然语言的力量

零代码手写：我输入的全是中文自然语言，最长的一句也不过50字。没有写过一行Python，没有配置过一个JSON。

自主架构设计：三种下载方案、双通知系统、模块化结构、错误处理、断点续传......这些都是Claude基于最佳实践自主添加的。

文档即规范：8份文档自动生成，彼此关联不重复。README是概览，QUICKSTART是上手，HOW_TO_USE是教程，FILES是索引。每份文档都有明确受众和目的。

踩过的坑

TDD的误用：在爬虫这种依赖外部环境的任务中，TDD成本收益比太低。我花了约1小时在TDD上，最终放弃。教训：不要盲目套用方法论，要根据场景选择工具。

需求表达模糊：我第一次说"发送给小刘"，实际是"张璐"。虽然Claude能自主选择和纠正，但清晰需求能大幅提升效率。

年份分类失败：目前所有文章都在unknown目录，按年份分类的逻辑没生效。原因可能是HTML结构复杂，日期提取规则需要优化。这是下一步要解决的问题。

反思：人的角色变了

这次实践让我重新思考"编程"的定义。在AI时代，编程可能更接近"用自然语言描述问题和约束，让AI生成并迭代解决方案"。人的角色从"代码编写者"变成了"需求设计者"和"方向把控者"。

我在这个项目中做了什么？提出需求（14:54:55）、补充约束（15:07:37）、纠正细节（16:31:21）、调整策略（22:13:46）。仅此而已。其他所有工作——调研、设计、编码、测试、文档、部署——都是Claude完成的。

但这不意味着人的作用降低了。恰恰相反，在这种新范式下，人的判断力变得更加重要：什么时候该坚持（使用多种方案），什么时候该放弃（TDD），什么细节需要明确（通知发给谁）——这些都需要经验和直觉。

截至我写下这段文字，下载程序还在运行。根据当前速度（每分钟约10篇），预计还需5-6小时完成全部3213篇文章。但我不需要守着——张璐的飞书每60秒会收到进度更新，出现异常也会立即通知。

这就是AI时代的工作方式：用自然语言描述问题，让AI自主执行，通过结构化反馈监控进度，在关键节点做出判断。7小时36分钟，从一句话到一个完整系统。没有写过一行代码，但创建了15个脚本、8份文档、23个目录。这不是魔法，这是Claude Code。

---